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ABSTRACT 


AUTHOR:  LTC  Catherine  A.  McNerney 

TITLE:  Transforming  The  Army’s  Legacy  Personnel  Systems 

FORMAT:  Strategy  Research  Project 

DATE:  07  April  2003  PAGES:  44  CLASSIFICATION:  Unclassified 

The  Army  Transformation  Roadmap  acknowledges  that  “cultural  transformation  of  people 
must  precede  transformation  of  processes,  organizations,  and  technology.”  The  technology 
available  today  is  clearly  capable  of  all  the  personnel  processes  required  to  support  soldiers.  If 
these  processes  do  not  change  however,  the  technology  used  in  personnel  transformation  will 
be  nothing  more  than  "webification"  of  archaic  practices. 

This  paper  focuses  on  personnel  transformation  as  the  strategic  enabler  for  Army 
transformation.  It  will  start  by  outlining  the  current  state  of  the  existing  personnel  systems  to 
portray  transformation  challenges,  including  the  fact  that  they  represent  the  single  largest  IT 
maintenance  bill  in  the  Army.  It  will  then  identify  key  functional  issues  requiring  change  before 
transformation  can  occur,  showing  how  these  issues  are  a  microcosm  of  the  larger  functional 
environment.  These  issues  will  then  be  linked  to  the  current  migration  path,  including  the 
concept  and  implications  associated  with  requirement  for  all  services  to  migrate  a  single  DOD 
system.  Before  concluding,  the  paper  presents  a  procedural  approach  for  change  where 
technology  is  a  means  rather  than  an  end,  giving  it  significantly  more  value  as  an  Army 
Transformation  enabler.  It  concludes  by  postulating  that  personnel  transformation  will 
significantly  impede  Army  Transformation  if  the  ongoing  effort  fails. 
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TRANSFORMING  THE  ARMY’S  LEGACY  PERSONNEL  SYSTEMS 


“Army  readiness  is  inextricably  linked  to  the  well-being  of  our  people.  Our 
success  depends  on  the  whole  team  -  soldiers,  civilians,  families  -  all  of  whom 
serve  the  nation.  Strategic  structures  provide  soldiers  and  families  the  resources 
to  be  self-reliant  both  when  the  force  is  deployed  and  when  it  is  at  home.’1 

-  General  Erik  K.  Shinseki 


The  epigraph  above  was  taken  from  General  ErikShinseki’s  arrival  speech,  given  when 
he  assumed  his  duties  as  Army  Chief  of  Staff  (CSA)  in  June  1999.  Linking  readiness  to  the 
well-being  of  the  individuals  making  up  the  Army  team  set  the  tone  to  identify  people  as  the 
most  important  asset  in  the  Army.  While  such  a  statement  may  seem  obvious,  highlighting 
people  with  that  spotlight  is  a  cornerstone  of  the  Army’s  transformation  effort.  Indeed,  people 
are  the  first  of  three  interdependent  elements  in  the  Army  Vision,  and  the  Army  Transformation 
Roadmap  acknowledges  that  “cultural  transformation  of  people  must  precede  transformation  of 
processes,  organizations,  and  technology.”2 

The  purpose  of  this  paper  is  to  examine  the  current  set  of  personnel  systems  with  an  eye 
on  how  these  systems  can  be  transformed  to  support  the  operational  and  institutional  “Big 
Army”  transformation  effort  currently  underway.  Transforming  the  Army’s  organizations, 
equipment,  and  doctrine  will  fail  if  the  Army  fails  to  transform  the  personnel  systems  designed  to 
support  those  organizations  with  the  Army’s  most  valued  entity  -  soldiers.  The  method  by 
which  the  personnel  community  transforms  will  have  significant  resource  implications, 
depending  on  how  this  transformation  is  effected.  This  effort  focuses  on  personnel 
transformation  as  the  strategic  enabler  for  the  Army  Transformation,  and  is  divided  into  four 
segments. 

The  first  segment  outlines  the  current  state  of  the  existing  legacy  systems  as  a  means  of 
portraying  challenges  to  this  transformation  effort.  The  highlighted  issues  will  significantly 
impact  any  effort  to  transform  the  legacy  personnel  systems,  regardless  of  the  path  chosen. 
Much  of  the  system-level  discussion  will  revolve  around  the  Headquarters,  Department  of  the 
Army  (HQDA)  level  database  because  the  Army’s  Deputy  Chief  of  Staff  (DCS,  G1,  henceforth 
referred  to  as  G1)  uses  it  as  the  data  source  to  fulfill  the  Army’s  Title  10,  United  States  Code  (10 
USC)  personnel  reporting  responsibilities.3 

The  second  segment  identifies  several  key  functional  issues  requiring  change  before 
transformation  can  occur.  These  issues  are  embedded  in  the  culture  of  the  personnel 
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community,  and  are  a  microcosm  of  the  larger  functional  environment  governing  the  personnel 
systems.  As  stewards  of  its  processes,  the  personnel  community  needs  to  focus  on 
modernizing  how  it  does  business.  Without  changing  those  processes,  the  technology  used  in 
personnel  transformation  will  be  nothing  more  than  what  might  be  referred  to  as  Webification”  of 
archaic  practices.  That  is,  putting  a  web  front  end  on  an  application  as  the  single  concession  to 
modernization. 

The  third  segment  outlines  the  present  systems  migration  path.  This  will  include  the 
concept  and  implications  associated  with  the  Department  of  Defense  (DOD)  requirement  for  all 
services  to  migrate  to  the  Defense  Integrated  Military  Human  Resource  System  (DIMHRS), 
which  will  serve  as  the  DOD  combined  personnel  and  pay  application. 

The  final  segment,  assuming  the  Army  can  overcome  or  at  least  mitigate  challenges 
identified  in  the  previous  segments,  presents  an  approach  for  change  which  is  procedural  rather 
than  technical.  The  emphasis  is  on  functional  procedures  because  technology,  as  a  means 
rather  than  an  end,  has  significantly  more  value  as  an  Army  Transformation  enabler. 

The  Army  Transformation  Roadmap  defines  transformation  as  “a  continuous  process  that 
creates  a  culture  of  innovation,  which  in  turn  seeks  to  exploit  and  shape  the  changing  conduct  of 
military  competition.’4  This  discussion  on  Army  Transformation  starts  with  people  and  the 
Army’s  ability  to  transform  the  systems  designed  to  sustain  their  force  structure.  Again, 
technology  should  be  treated  as  merely  a  means  to  an  end;  important  to  leverage,  but  not  the 
transformation  driver.  Today’s  technology  is  clearly  capable  of  all  the  processes  required  to 
support  soldiers  throughout  their  tenure  in  the  Army.  Identifying  the  desired  and  required 
processes  and  implementing  them  in  technology  is  more  crucial  than  the  technology  itself.  In 
other  words,  identifying  the  functional  requirements  is  more  critical  to  the  process  and,  at  least 
in  the  case  of  the  personnel  systems,  has  been  harder  to  accomplish  than  applying  technology 
to  produce  the  solution. 

THE  CURRENT  SYSTEM 

Lieutenant  General  John  LeMoyne,  the  Army’s  G1,  identifies  personnel  transformation  as 
the  strategic  enabler  of  Army  transformation.  He  clearly  states  his  intention  to  accomplish 
personnel  systems’  transformation  ahead  of  the  Army’s  transformation  effort,  so  when 
transformation  occurs,  the  personnel  community  is  already  there,  waiting.5  This  is  a 
monumental  task,  given  the  current  state  of  the  personnel  systems  and  the  bureaucracies 
supporting  them.  This  section  will  outline  six  issues  which  impede  efforts  to  transition  the 
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personnel  systems  into  the  Army’s  Information  Technology  (IT)  enterprise.  The  first  two  issues, 
numbers  of  systems  and  funding,  are  tied  closely  together. 

NUMBERS  OF  SYSTEMS  AND  FUNDING 

According  to  a  June  2001  Office  of  the  Director  of  Information  Systems  for  Command  and 
Control,  Communication,  and  Computers  (DISC4)  briefing  to  Dr.  Oscar  (Acting  Army  Acquisition 
Executive  (AAE)),  Army  business  systems  account  for  sixty  cents  of  every  Army  dollar  spent, 
where  the  single  largest  group  are  personnel  systems,  accounting  for  182  out  of  574  of  the 

c 

identified  systems.  The  briefing  goes  on  to  identify  existing  shortfalls  in  moving  to  an 
enterprise  system,  including  lack  of  funding,  failure  to  identify  an  enterprise  solution  for  business 
systems,  and  the  heretofore  single-minded  focus  on  the  war-fighting  systems.  These  points  will 
be  discussed  in  later  sections.  In  July  2001  testimony  before  the  Senate  Personnel 
Subcommittee  (for  the  Committee  on  Army  Services),  the  Deputy  Chief  of  Staff  for  Personnel 
(DCSPER),  LTG  Timothy  Maude,  stated  that  “the  Army  employed  over  350  Army  personnel 
automation  and  information  systems  in  support  of  1,170  processes.’7  The  numerical  difference 
between  the  DCSPER  and  DISC4  numbers  can  be  attributed  to  the  fact  that  the  Y2K  database 
counted  only  those  systems  deemed  operationally  “critical.”  The  DCSPER,  meanwhile,  counted 
many  stand-alone  applications  and  databases  as  systems  as  a  means  to  identify  the  function 
set  required  to  support  the  full  spectrum  of  personnel  activities.  There  are  two  key  points  here. 
First,  maintenance  for  this  group  of  personnel  “systems,”  whether  true  “systems”  or  stand-alone 
applications,  is  the  single  largest  IT  maintenance  bill  in  the  Army.8  Second,  only  a  handful  of 
these  systems  fall  under  the  purview  of  the  acquisition  community  (e.g.,  are  organized  under  a 
product  or  project  manager  (PM),  in  a  Program  Executive  Office  (PEO),  or  receive  HQDA 

secretariat-level  oversight  from  the  Army  Acquisition  Executive).9  This  means  in  most  cases, 
the  formal  oversight  required  for  acquisition  systems  does  not  occur.  Without  casting 
aspersions,  it  is  safe  to  say  resource  and  funding  implications  on  a  multimillion  dollar  family  of 
systems  functioning  without  oversight  are  significant.  In  discussing  the  oversight  required,  it 
then  becomes  important  to  consider  the  genesis  of  the  Army  Acquisition  Corps  (AAC).  The 
AAC  was  formed  to  provide  the  Army  with  a  professional  acquisitionist.  Specifically,  the  AAC 
process  was  developed  to  provide  the  Army  a  group  of  individuals  educated  in  and  familiar  with 
the  laws,  regulations,  and  nuances  inherent  in  the  set  of  processes  associated  with  developing, 
testing,  and  fielding  equipment.  These  individuals  also  have  to  understand  the  additional 
intricacies  involved  for  programs  scaled  in  sufficient  size  to  provide  the  Army  with  everything 
from  modern  “c-rations”  to  precision-guided  munitions  and  digitization  of  the  battlefield.  The 
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laws  and  related  oversight  requirements,  meanwhile,  were  put  into  place  as  a  means  to  ensure 
DOD  and,  more  importantly,  the  U.S.  taxpayer,  get  value  for  their  defense  dollar.  Most 
programs,  regardless  of  their  dollar  values,  were  specifically  removed  from  their  origins  in  the 
functional  communities  because  those  communities  did  not  have  the  acquisition-related 
backgrounds  and  education  thought  necessary  to  allow  them  to  act  as  good  stewards  of  the  tax 
dollars  given  to  those  programs.  In  terms  of  the  IT  systems,  the  Army  has  come  to  understand 
the  value  of  an  enterprise  approach.  Two  key  attributes  of  an  enterprise  approach  are  the 
potential  monetary  savings  it  garners,  and  the  ability  to  establish  standardized  Army  and  joint 
processes.  For  reasons  that  are  not  clear,  the  personnel  IT  systems  have  stayed  away  from  the 
acquisition  umbrella  and  therefore  have  not  benefited  from  the  Army’s  move  to  an  enterprise 
approach. 

The  Army  Knowledge  Management  (AKM)  policies  originating  from  the  Chief  Information 
Officer  /  Deputy  Chief  of  Staff,  G6  (CIO/G6),  has  started  to  address  the  enterprise  shortcomings 
Army-wide  in  the  form  of  the  AKM  Memorandums.  These  policies,  signed  by  the  Secretary  of 
the  Army  (SECARMY),  CSA,  Vice  Chief  of  Staff,  Army  (VCSA),  or  the  CIO/G6,  take  IT  funding 
away  from  organizations  whose  systems  do  not  adhere  to  the  Army  Enterprise  concept  outlined 

in  the  AKM  Strategic  Plan.10  Many  times,  however,  funding  for  these  systems  is  so  deeply 
embedded  in  the  sponsoring  organizations’  funding  line,  distinguishing  it  from  non-IT  funding 
has  been  difficult,  if  not  impossible.  This  is  certainly  true  in  the  personnel  systems,  where  many 
of  the  systems,  applications,  and  databases  have  never  had  a  separate  funding  line,  and  for 
purposes  of  establishing  an  enterprise  solution,  the  funding  trails  give  little  indication  these 
systems  ever  existed.  The  GTs  Personnel  Transformation  Task  Force  (PT  TF)  adds  another 
management  layer  which  inadvertently  serves  to  shield  these  personnel  systems  and  their 
funding  lines  from  CIO/G6  visibility.  This  further  complicates  the  CIO/G6’s  ability  to  track  IT 
funding,  because  neither  the  task  force  nor  the  G1  have  visibility  over  funding  execution.  Both 
organizations  can  see  money  being  spent,  but  cannot  necessarily  determine  what  the 
expenditures  buy. 

The  remaining  four  issues,  addressing  slightly  more  technical  aspects,  are  somewhat 
more  nebulous  to  define  than  funding  and  system  numbers,  and  present  obstacles  almost  as 
significant.  Two  of  these  issues,  data  definition  and  system  documentation,  are  closely 
interrelated. 
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DATA  DEFINITION  AND  SYSTEM  DOCUMENTATION 

The  vast  majority  of  these  systems,  applications,  and  databases  are  considered  “legacy”. 
That  is,  they  are  candidates  for  phase-out,  upgrade,  or  replacement.  This  is  usually  due  to  one 
or  more  of  the  following:  they  have  no  or  limited  vendor  support  for  maintenance  and  upgrades; 
they  are  not  interoperable  with  other  systems,  and  the  cost  to  make  them  interoperable  is 
prohibitive;  functional  requirements  Business  Process  Reengineering  (BPR)  has  rendered  the 
application  obsolete,  and  the  cost  to  change  the  code  is  prohibitive.  For  example,  it  may  be 
cheaper  to  start  from  scratch  than  to  change  the  existing  code.  Legacy  systems  have  a  greater 
range  of  data  definitions  than  optimal,  which  requires  an  Application  Program  Interface  (API)  be 
written  to  act  as  a  “translator”  between  applications.  Oftentimes  APIs,  like  the  applications 
themselves,  date  back  to  the  70s  and  80s,  and  tracing  the  documentation  is  problematic  at  best. 
One  of  the  better  examples  of  this  in  the  personnel  community  family  of  systems  is  the  Total 
Army  Personnel  Database  (TAPDB),  which  falls  under  the  U.  S.  Total  Army  Personnel 
Command  (PERSCOM)  Information  Systems  Directorate  (known  as  PERSINS-D). 

TAPDB,  normally  referred  to  as  a  single  entity,  is  actually  a  set  of  five  personnel 
databases:  TAPDB-AE  (containing  Active  Enlisted  personnel  data),  TAPDB-AO  (containing 
Active  Officer  personnel  data),  TAPDB-CP  (containing  Civilian  Personnel  data),  TAPDB-NG 
(containing  Army  National  Guard  (ARNG)  personnel  data),  and  TAPDB-R  (containing  United 
States  Army  Reserve  (USAR)  personnel  data).  The  legacy  databases  that  make  up  TAPDB  run 
on  mainframe  computers  using  the  COBOL  programming  language,  important  to  note  only  as 
an  age  indicator.  TAPDB  has  its  own  set  of  data  definitions  which  do  not  necessarily  correlate 
with  either  the  Army  or  the  Department  of  Defense  (DOD)  data  dictionaries.  In  the  over  twenty- 
five  years  of  TAPDB  existence,  the  API  surrounding  TAPDB  has  grown  to  accommodate  the 
differences  between  it  and  the  applications  feeding  it.  One  example  of  the  dichotomy  between 
definitions  involves  state  names.  The  U.S.  Post  Office  uses  two-letter  abbreviations  to  annotate 
state  names  (e.g.,  VA  for  Virginia).  This  procedure  is  what  both  the  Army  and  DOD  dictionaries 
specify  for  use.  TAPDB,  however,  uses  a  numerical  designation  for  states’  names,  having 
established  a  data  table  for  that  purpose.  All  the  personnel  systems  getting  data  from  or 
passing  data  to  TAPDB  have  to  use  a  translator  to  read  the  correct  state  name.  This  particular 
example  is  well  documented,  but  there  are  -  literally  -  hundreds  of  these  rules  in  TAPDB,  and 

unfortunately,  most  of  this  API  is  not  well  documented.1 1  Modifying  the  API  to  accommodate 
application  code  changes  becomes  a  complicated  undertaking.  Such  modifications  might 
include  simple  Commercial  Off  The  Shelf  (COTS)  software  package  upgrades  (e.g.,  moving 
from  Windows  Explorer  Version  5.x  to  Version  8.0).  Add  to  this  the  fact  that  programmers 
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experienced  in  the  languages  used  in  many  of  the  legacy  systems  (e.g.,  COBOL,  Ada,  etc.)  can 
cost  two  to  three  times  that  of  other  language  programmers,  and  legacy  system  maintenance,  in 
addition  to  being  complicated,  has  become  very  costly.12 

DATA  RECONCILIATION 

The  fifth  issue  is  data  reconciliation.  Most  of  the  legacy  personnel  systems  have  little  or 
no  automated  methods  to  reconcile  its  data.  This  has  a  direct  impact  on  data  accuracy  in  the 
field-level  systems,  applications,  and  databases,  and  on  TAPDB,  which  serves  as  the  HQDA- 
level  personnel  database.  This  data  accuracy  impact  actually  manifests  itself  on  two  levels,  first 
with  a  user  sitting  at  a  terminal  inputting  data,  and  second  when  data  is  externally  passed  from 
one  application  or  system  to  another.  Starting  with  an  example  at  the  user-level  input,  if  the 
system  code  is  not  written  to  automatically  compare  the  input  data  value  against  accepted 
values  embedded  in  the  application,  a  user  could  enter  erroneous  data.  An  example  of  this  is 
where,  absent  a  coding  rule  regarding  gender,  a  user  could  change  a  male’s  medical  status  to 
pregnant.  These  types  of  errors  are  more  infrequent,  as  system  owners  have  added  code  to 
perform  the  reconciliation. 

The  more  prevalent  reconciliation  errors  occur  as  data  is  exchanged  externally,  which 
points  back  to  an  API.  Wherever  the  possibility  of  conflicting  data  values  exists,  the  system  API 
should  be  coded  to  translate  values  into  the  form  acceptable  at  the  receiving  application. 

Where  systems  are  not  capable  of  reconciliation,  soldiers  are  required  to  correct  the  data 
manually,  which  is  extremely  burdensome  in  terms  of  the  manpower  required  to  make  these 
data  corrections.  Focusing  on  two  circumstances  where  manual  intervention  is  required,  this 
discussion  first  describes  a  specific  interaction  between  two  legacy  systems  and  its  resulting 
workload,  and  follows  with  a  generic  description  of  error  resolution  at  the  user  level. 

TAPDB,  as  mentioned  earlier,  serves  as  the  HQDA-level  personnel  database.  As  such,  it 
interfaces  with  any  system,  application,  or  database  whenever  that  system  either  needs  data 
resident  in  TAPDB,  or  is  one  of  the  systems  providing  TAPDB  with  information  required  at 
HQDA  level.  This  older  legacy  system  requires  information  in  transactions,  which  are  small 
data  packages  collated  together  in  specified  formats  using  a  rigid  rule-set  provided  by 
PERSINS-D.  In  an  effort  to  minimize  manual  intervention,  TAPDB’s  extensive  API  should  have 
translation  rules  to  give  and  receive  data  to  the  systems  with  which  it  interfaces.  Unfortunately, 
while  the  translation  rules  exist,  they  oftentimes  side  in  favor  of  minimizing  the  TAPDB  workload 
by  rejecting  transactions  which  do  not  match  their  rigid  rule-set.  Interaction  with  the  unit-level 
personnel  system  provides  some  of  the  best  examples  of  this  phenomena. 
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The  unit-level  personnel  system  responsible  for  the  majority  of  Active  Army  soldier 

information  is  called  the  Standard  Installation  /  Division  Personnel  System  (SIDPERS-3).13 
Another  legacy  system,  SIDPERS-3  will  be  replaced  by  the  Army  Human  Resource  System 

(AHRS)  E-MILPO  (referring  to  “electronic  military  personnel  office”)  in  March  2003. 14  In  the 
meantime,  SIDPERS-3  continues  to  send  and  receive  transactions  with  and  from  TAPDB,  which 
has  been  the  source  of  some  consternation  at  the  Army’s  field-level  personnel  units.  The 
consternation  arises  from  the  large  amount  of  reconciliation  required  by  units  in  response  to  the 
transactions  rejected  by  TAPDB.  The  example  involving  the  way  soldiers  are  accounted  for  as 
they  move  from  one  location  to  another  (an  “arrival”),  is  discussed  in  detail  in  a  later  section. 
Another  example  is  where  an  authorized  user  goes  into  the  system  to  change  a  soldier’s  date  of 
rank.  There  are  certain  promotions  and  reductions  in  the  enlisted  ranks  which  are  the  unit 
commander’s  responsibility,  versus  those  promotions  resulting  from  centralized  boards  held  at 
HQDA  level.  However,  when  an  authorized  user  enters  a  rank  change  based  on  the  legal 
promotion  or  reduction  orders  signed  by  the  authorizing  commander,  TAPDB  rejects  the 
transaction.  This  has  resource  impacts  on  several  people.  First,  it  costs  time  and  effort  for 
personnel  specialists  entering  the  data  to  contact  TAPDB  representatives  and  get  the 
information  corrected  at  the  headquarters  level  system,  and  more  importantly,  it  significantly 
impacts  the  soldier  whose  rank  was  being  corrected.  Either  the  soldier  is  unable  to  get  the 
higher  pay  level  of  the  new  grade,  or  sometimes  worse,  in  the  case  of  a  reduction,  the  soldier 
continues  to  receive  the  higher  pay  until  the  correction  is  made.  The  soldier  is  then  forced  to 
repay  the  government  when  their  rank  is  finally  corrected,  oftentimes  resulting  in  a  financial 
hardship  for  them. 

The  example  given  above  is  one  of  many  involving  rejected  transactions.  At  one  point, 
the  rejected  transactions  numbered  in  the  thousands  on  each  installation,  although  the 
architecture  redesign  of  SIDPERS-3  into  the  “SuperServer”  reduced,  but  did  not  vanquish,  the 
workload  considerably.15  Perhaps  more  important  to  note,  as  part  of  the  E-MILPO  development 
agreement  within  the  personnel  community,  this  new  system  will  be  required  to  develop  the 
same  TAPDB  transactions  SIDPERS-3  currently  sends,  still  vulnerable  to  TAPDB  rejection  and 
the  resultant  user-level  soldier  workload. 

THE  PROMISE  THAT  NEVER  WAS 

The  last  of  the  six  issues  relevant  to  the  current  systems  and  potentially  impacting  the 
personnel  system  transformation  effort  is  what  could  be  considered  the  promise  that  never  was. 
ITAPDB  is  the  Integrated  Total  Army  Personnel  Database,  and  like  TAPDB,  it  belongs  to 
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PERSCOM’s  PERSINS-D.  In  concept,  it  was  to  replace  TAPDB  with  a  real-time,  updateable 
database.  It  was  to  consolidate  the  five  current  databases  (AE,  AO,  CP,  NG,  and  R)  in  to  this 
single  database,  hence  the  reference  to  “integrated.”  Had  this  been  what  was  delivered, 

ITAPDB  would  have  been  the  Army  Enterprise  Personnel  Database  referred  to  in  the  July  / 
August  2002  issue  of  Army  AL&T  Magazine  on  personnel  transformation.  As  such,  it  would 
have  been  in  perfect  position  to  transition  Army  personnel  data,  and  systems,  to  the  DOD 
system,  DIMHRS.  Instead  ITAPDB  was  delivered  in  October  2002  as  a  “data  store”  available  to 
limited  functional  users  as  a  source  of  personnel  data  consolidated  from  the  five  personnel 
databases.  The  fact  that  users  can,  for  the  first  time,  go  to  one  source  for  information  on 
soldiers  and  civilians  from  all  Army  components  is  a  positive  step.  As  a  static  snapshot-in-time, 
however,  users  cannot  update  it  and  in  fact,  are  still  required  to  update  the  mainframe  TAPDBs 
via  transactions.  ITAPDB  development  was  millions  of  dollars  in  the  making,  over  budget,  and 
the  watered-down  product  was  delivered  a  year  past  the  projected  schedule.17  This  is  relevant 
to  any  personnel  transformation  discussion  for  several  reasons.  First,  ITAPDB  represents  the 
poster-child  for  why  programs  require  oversight  to  the  degree  specified  in  10  USC  for  Major 
Defense  Acquisition  Programs  (MDAP).18  While  some  would  argue  ITAPDB  was  and  is  not 
considered  an  MDAP,  the  counter  argument  is  that  it  should  have  been.  Governing  acquisition 
in  DOD,  10  USC  and  the  DOD  5000  series  regulations  list  certain  criteria  to  designate  a 
program  as  an  MDAP.  The  funding  level  is  one  criterion,  referring  to  the  total  life  cycle  cost  of 
the  system,  and  the  other  is  the  level  of  a  program’s  visibility.  This  is  basically  a  service 
decision  and/or  that  of  the  Joint  Requirements  Oversight  Council  (JROC).19  Conceptually, 
ITAPDB  was  to  be  the  Army  source  of  personnel  data  for  migration  to  DIMHRS,  “representing 
the  largest  deployment  of  an  off-the-shelf  human  resource  software,  either  commercial  or 

on 

military.’  As  such,  it  is  not  unreasonable  to  require  MDAP-level  oversight  for  ITAPDB. 

Next,  it  is  important  to  note  one  of  the  key  reasons  ITAPDB  failed  to  become  the  single, 
updateable  database  encompassing  personnel  data  from  all  Army  components  remains 
unchanged.  The  biggest  challenge  to  establish  a  personnel  enterprise  database  is  the 
difference  in  data  definitions  between  components.  Specifically,  some  of  the  same  data 
elements  used  in  the  Active  Army  to  mean  one  thing  are  used  for  something  else  in  the  Reserve 
Component  databases,  and  may  even  have  different  meanings  between  the  USAR  and  ARNG 
databases.  Additionally,  some  data  elements,  while  having  the  same  meaning  in  all  three 
components,  may  have  different  values.  While  additional  values  can  be  accommodated,  coding 
is  more  complicated,  and  therefore  more  costly.  The  data  definition  problem,  added  with  the 
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associated  cultural  reluctance  to  change,  represents  a  significant  impediment  for  any  effort  to 
transform  Army  personnel  systems. 

Finally,  attempts  to  bring  the  components  together  are  hampered  by  the  specific  10  USC 
direction  given  to  separate  Reserve  Component  IT  funding  from  Active  Component  funding  21 
While  General  Shinseki  credited  former  CSA  General  Dennis  Reimer  with  completing  the  effort 

to  solidify  the  Army  from  what  were  three  separate  pieces,  the  law  on  IT  funding  clearly 

22 

delineates  between  components. 

FUNCTIONAL  ISSUES 

This  segment,  harkening  back  to  where  the  Army  Transformation  Roadmap 
acknowledges  “cultural  transformation  of  people  must  precede  transformation  of  processes, 

23 

organizations,  and  technology”,  focuses  on  functional  processes.  Change  has  to  start  with  the 
processes  before  technology  can  be  brought  to  bear  in  the  transformation  process. 

Starting  with  an  examination  of  the  current  personnel  system  structure  and  the  associated 
Rules  Of  Engagement  (ROE),  this  segment  suggests  remedies  short  of  the  technical 
information  system  overhaul  required  for  the  long-term  viability  of  the  personnel  systems 
through  transformation.  Specifically,  there  exist  today,  several  long-standing  ROE  which,  if 
brought  forward,  will  cripple  the  personnel  transformation  effort.  These  ROE  are  sometimes 
codified  in  regulations,  and  other  times  not.  Two  of  these  ROE  are  considered  the  most  critical 
and  require  change  on  the  level  of  business  system  re-engineering. 

PERSPECTIVE 


“One  Does  Not  Equal  One.” 

— LTG  Timothy  Maude,  USA 

The  above  epigraph  from  LTG  Timothy  Maude  cuts  directly  to  the  heart  of  perhaps  the 
biggest  dichotomy  in  the  personnel  community  today.  This  dichotomy,  highlighted  as  the  first  of 
the  two  ROE  under  discussion,  has  its  genesis  in  10  USC  and  the  legal  mandate  to  man  the 

force.  The  intent  of  the  law  is  for  the  service  chiefs  to  man  the  program  force  as  codified  in 
the  force  structure  identified  by  the  service  operators.  In  the  Army’s  case,  this  is  the  Deputy 
Chief  of  Staff,  (DCS,G3,  henceforth  referred  to  as  G3).  The  G1  has  two  functions  in  this:  the 
accounting  function,  which  ensures  the  Army  is  at  the  correct  end  strength  at  the  end  of  the 
fiscal  year  for  the  10  USC  requirement  to  report  to  Congress,  and  the  responsibility  to  distribute 
the  force.  That  is,  the  G1  assigns  soldiers  according  to  the  G3’s  force  structure.  Both  of 
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these  functions  rely  heavily  on  force  structure  in  terms  of  organizational  positions  (spaces), 
rather  than  individual  soldiers  (faces).  Put  another  way,  the  G1  is  concerned  with  what  the 
Army  should  look  like  (structure),  versus  the  reality  facing  commanders  daily,  which  is  what  the 
Army  actually  looks  like  (names).  Field  commanders  are  held  accountable  for  personnel  asset 
visibility.  That  is,  10  USC  gives  the  commander  responsibility  and  authority  (including  Uniform 
Code  of  Military  Justice  authority)  to  account  for  their  soldiers,  as  opposed  to  the  positions  these 

nc 

soldiers  encumber  in  the  force  structure.  Implementing  these  divergent  requirements  can  be 
confusing. 

The  G1,  via  its  Field  Operating  Agency,  PERSCOM,  assigns  soldiers  to  the  installation 
level.  So,  for  example,  100  soldiers  may  be  assigned  to  one  of  the  divisions  at  Fort  Hood. 
However,  the  installation  G1,  using  the  field-level  system,  knows  one  of  the  battalion 
commanders  in  the  other  division  is  short,  or  lacking  soldiers,  which  will  be  critical  for  their 
upcoming  deployment.  With  agreement  from  his  commander,  the  installation  G1  reassigns  50 
of  the  100  inbound  soldiers  from  one  division  to  the  other.  Though  all  100  soldiers  are 
physically  located  on  Fort  Hood,  50  are  now  in  a  unit  different  from  that  assigned  by 
PERSCOM,  presumably  placed  into  valid  positions.  There  are  numerous  variations  to  this 
example,  many  of  which  are  invisible  to  PERSCOM  until  they  go  to  move  a  soldier  for  whatever 
reason.  This  results  in  balanced  books  at  installation  but  not  Major  Army  Command  (MACOM) 
levels,  or  vice  versa,  depending  on  perspective.  The  commander  in  the  field,  meanwhile, 
remains  solely  concerned  about  the  soldiers  assigned  to  the  unit,  which  is  anywhere  up  to  four 
layers  removed  from  the  PERSCOM  assignment.  The  field  commander  needs  to  know  where 
the  soldiers  are,  whether  they  have  been  paid,  whether  their  training  is  up  to  date,  whether  they 
have  their  field  equipment,  what  UCMJ  offenses  they  might  have  committed,  who  is  in  the 
hospital,  whether  or  not  they  can  deploy,  etc.  Further,  the  commander  is  required  to  report 
these  dispositions  in  significant  detail  in  the  monthly  Unit  Status  Report  (USR).  These  monthly 
reports  start  at  the  battalion  and  separate  company  level,  and  are  consolidated  up  to  the 
division  and  corps  levels.  While  the  personnel  portions  of  the  reports  are  prepared  by  the  unit 
G1 ,  or  equivalent,  the  USR  itself  is  an  operational  requirement  and  therefore  a  G3  responsibility. 

Continuing  this  vignette,  imagine  a  staff  officer  now  working  for  the  Army  G1  in  the 
Pentagon.  The  officer  has  just  been  tasked  to  accompany  the  G1  to  the  CSA’s  monthly  USR 
reconciliation  meeting.  During  this  meeting,  the  infantry  division  commander  at  Fort  Hood 
reports  through  the  USR  that  they  are  short  40  infantry  soldiers  in  the  division.  The  CSA  turns 
to  the  G1  and  asks  how  this  can  be,  and  wants  to  know  what  is  being  done  to  fix  the  problem. 
The  staff  officer  whispers  to  the  G1  that  Fort  Hood  is  showing  an  “overage”  of  17  infantry 


10 


soldiers,  and  admits  their  office  does  not  know  the  unit  strength  of  that  unit  (or  any  unit  below 
MACOM  /  installation  level)  because  they  do  not  use  the  field-level  system  that  accounts  for 
faces  versus  spaces.  The  headquarters  level  system  distributes  soldiers  according  to  force 
structure  requirements,  and  as  far  as  the  staff  officer  knows,  the  requirement  was  met  when 
they  sent  100  infantry  soldiers  to  Fort  Hood.  The  G1  fires  the  staff  officer.  And  when  the  G1 
finds  out  the  headquarters  level  distribution  system  they  rely  on  contains  information  from  30  to 
45  days  old,  he  tries  to  find  a  way  to  demote  the  staff  officer;  as  a  former  commander,  the  G1 
knows  the  USR  information  provided  by  the  G3  is  no  more  than  two  weeks  old.  All  this,  and  the 
staff  officer  still  has  not  told  the  G1  the  only  way  to  ascertain  a  specific  unit  strength  is  to  call  the 
unit  in  Texas  and  ask  them  to  share  their  strength  numbers.  The  same  would  apply  if  the  unit  in 
Texas  had  deployed  to  Afghanistan  or  Kuwait,  though  perhaps  without  a  phone  conveniently 
close-by. 

Moving  back  to  transformation,  take  the  case  of  the  mismatch  in  strength  numbers  and 
multiply  it  by  the  strength  of  the  Army,  which  is  approximately  1 .2  million  soldiers.  Both  HQDA 
and  the  installation  and/or  division  commander  at  Fort  Hood  are  working  within  their  10  USC 
authority.  The  field  commander  has  deliberately  assigned  soldiers  contrary  to  direction  received 
from  the  HQDA  distribution  system,  but  is  exercising  a  commander’s  10  USC  authority  and 
responsibility  to  “man  the  force.”  The  bottom  line  is  the  field  commander’s  picture  of  personnel, 
as  depicted  by  the  field-level  system,  is  different  from  that  depicted  by  the  HQDA  level  system, 
and  as  long  as  the  two  continue  to  focus  on  their  respective  “interests,”  the  pictures  will  not 
match.  In  recognizing  the  need  for  transformation  in  the  personnel  systems,  the  late  LTG 
Maude  often  said  “One  does  not  equal  one.”27 

There  is  nothing  which  specifically  divides  the  10  USC  “man  the  force”  mandate  into  these 
two  camps.  Given  this  division  has  occurred,  the  Army  needs  to  rectify  the  problem  by 
recognizing  the  field  commanders'  requirements  for  personnel  asset  visibility.  Failing  that,  using 
HQDA  level  numbers  generated  by  that  system  in  a  transformed,  DOD-level  system  (i.e., 

DIMHRS)  will  prove  disastrous  for  the  Army,  since  the  proposed  DIMHRS  application  focuses 

28 

on  personnel  asset  visibility,  vice  force  structure.  The  answer  remains  one  single  database, 
giving  the  Army  one  single  people-picture  from  which  to  read. 

PERSONNEL  ASSET  VISIBILITY  -  PROCESS  OWNERSHIP 

The  second  ROE  requiring  change  prior  to  transformation  is  related  to  the  10  USC 
discussion  on  manning  the  force.  The  G1  distributes  the  force  according  to  G3  priorities. 

Moving  further  into  the  assignment  process,  soldiers  are  assigned  to  a  Unit  Identification  Code, 
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or  UIC,  which  normally  goes  to  the  battalion  or  separate  company  level.  As  the  Army’s  missions 
and  the  spectrum  of  war  have  broadened,  the  Army  has  come  to  use  task  organizations  as  a 
means  to  tailor  units  to  fit  specific  requirements.  The  process  of  task  organization  helps  to 
identify  and  match  requirements  with  personnel  whose  skills  and  training  are  commensurate 
with  whatever  requirement  has  been  identified.  In  most  cases  of  task  organizing  and  structuring 
a  force  for  specific  capabilities,  a  UIC  tailor-made  for  this  task-force  does  not  exist  and  has  to  be 
created  before  any  soldiers  can  be  assigned  against  that  unit.  The  issue  becomes  who  has  the 
authority  to  create  a  UIC.  Currently,  only  the  G3  has  that  authority.  The  G3  directs  that  the  unit 
or  task  force  be  created,  specifies  the  desired  force  structure  in  number  and  type  (e.g.,  one 
armor  brigade  commander,  three  13M-trained  soldiers,  etc.),  and  sets  the  implementation  date. 
Working  within  the  shortened  timeline  normally  associated  with  task  organizations,  the 
personnel  community  works  hard  to  assign  the  right  mix  of  soldiers  to  meet  the  G3’s  priorities. 
However,  since  the  G3  did  not  direct  the  UlC-making  person  to  complete  the  bureaucratic 
process  associated  with  UIC  creation,  soldiers  cannot  be  assigned  because  the  unit  does  not 
exist.  This  example  gives  the  impression  of  bureaucracy  amiss,  suggesting  the  possibility  of  a 
fix  by  addressing  existing  processes.  Unfortunately,  the  issue  is  considerably  more  complicated. 

Moving  back  to  the  commander’s  responsibilities  for  personnel  asset  visibility,  consider 
the  case  of  the  Congressional  requirement  to  account  for  Personnel  Tempo  (PERSTEMPO), 
referring  to  deployment  rates.  The  Army  is  required  to  report  soldiers  deployed  and  non- 

deployed  time  away  from  home.  The  owning  unit  to  which  a  soldier  is  assigned  is  in  a  position 
to  account  for  a  soldier’s  PERSTEMPO  time.  The  relationship  of  this  accounting  requirement  to 
UlCs  becomes  one  of  how  to  keep  track  of  and  report  this  time  away  from  home.  Going  back  to 
the  task  organization  scenario  described  above,  oftentimes  a  combat  arms  unit  (i.e.,  an  infantry 
battalion)  will  deploy  with  what  are  called  slices  of  support  elements,  referring  to  required 
portions  of  engineer,  signal,  field  artillery  assets,  etc.  It  is  not  unusual  for  some  portion  of  the 
infantry  battalion  to  not  deploy  for  any  number  of  reasons,  including,  for  example,  the  limited 
size  of  the  task  force,  or  soldiers  in  the  unit  who  are  non-deployable  due  to  illness.  From  a  pure 
accounting  standpoint,  moving  entire  units  of  people  in  a  systems  environment  to  a  deployed 
status  for  purposes  of  counting  days  away  from  home  is  much  simpler  than  having  to  enter 
hundreds  of  social  security  numbers  or  soldier  names.  Since  none  of  the  units  are  deploying  in 
their  entirety,  the  systems  solution  is  to  create  a  UIC  for  that  deployment  and  move  the 
deploying  soldiers  into  that  UIC.  However,  if  this  event  is  local  (i.e.,  a  training  exercise  held  “on- 
post”),  the  operations  community  is  not  going  to  create  a  separate  UIC  to  accommodate  this,  or 
any  other,  temporary  accounting  requirement.  A  bureaucratic  merry-go-round  results  when  the 
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G1  community,  saddled  with  the  PERSTEMPO  requirement,  is  held  hostage  by  the  G3  to 
account  for  personnel  because  the  G3  is  the  organization  authorized  to  create  a  UIC. 

Numerous  examples  unrelated  to  PERSTEMPO  abound.  This  process  is  a  source  of 
considerable  frustration  with  what  many  field  commanders  and  the  personnelists  supporting 
them  perceive  as  an  inflexible  bureaucracy.  Field  commanders  need  to  be  able  to  create  a 
UIC,  or  to  create  an  entity  with  similar  properties  to  properly  account  for  their  personnel. 

Without  that  capability,  technology  advances  will  not  give  commanders  the  flexibility  they  require 
to  account  for  their  soldiers. 

CURRENT  SYSTEMS  MIGRATION  PATH 

The  personnel  systems  are  in  something  of  a  state  of  flux  in  terms  of  migration  for  a 
number  of  reasons.  First,  ITAPDB  was  to  have  played  a  large  part  in  this  migration.  When 
ITAPDB  moved  from  being  a  single,  updateable  database  to  a  read-only  data  store  requiring 
updates  from  the  legacy  TAPDBs,  it  was  effectively  cut  out  of  the  transformation  effort. 

ITAPDB,  in  fact,  is  one  of  the  systems  DIMFIRS  will  replace.31  Another  reason  for  the  state  of 
uncertainty  in  the  migration  plan  is  that  many  of  the  systems  are  now  prohibited  from  making 
code  changes  to  their  software.  The  DIMFIRS  development,  fielding  and  implementation  plan 
mandated  a  code  moratorium  on  the  eighty-eight  legacy  systems  it  is  scheduled  to  replace.  The 
systems  interfacing  with  those  legacy  systems  were  included  as  well.  The  moratorium  applies 
to  all  services,  and  is  necessary  to  ensure  DIMFIRS  developers  are  not  coding  against  a 
baseline  which  has  changed.  Because  TAPDB  interfaces  with  so  many  systems  and 
applications,  the  moratorium  encompassed  most  of  the  personnel  community  systems.  This  is 
probably  a  positive  occurrence,  if  for  no  other  reason  than  to  act  as  a  forcing  function.  Instead 
of  planning  software  changes,  the  community  can  focus  on  where  to  go  from  today. 

After  a  positive  start  in  trying  to  identify  a  viable  migration  path,  the  G1  PT  TF  appears  to 
have  abandoned  its  initial  strategy.  In  February  2002,  the  G1  sponsored  a  personnel 
transformation  industry  day.  The  original  intent  of  this  industry  day  was  to  encourage  industry 
interest  and  participation  in  personnel  transformation;  one  of  the  lures  was  the  tantalizing 
possibility  of  a  lucrative  IT  contract  in  the  near  future.  Using  a  seminar-like  forum,  the  G1 
invited  industry  to  hear  the  senior  personnelists  outline  their  view  of  the  current  system  and 
challenges,  the  role  personnel  transformation  plays  in  Army  Transformation,  and  where,  in 
general  terms,  personnel  transformation  should  be  headed  in  support  of  the  Interim  and 
Objective  Force  transformation  efforts.  In  turn,  the  G1  invited  industry  to  participate  in  helping 
solve  these  challenges  by  answering  a  formally  released  Request  for  Information  (RFI).  The 
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RFI  responses  could  be  either  a  twenty  page  submission  addressing  the  full  scope  of  personnel 
transformation,  or  a  twelve  page  submission  focusing  on  a  specific  area  or  topic.  The  turnout 
was  impressive,  with  an  attendance  list  that  included  many,  if  not  most,  of  the  defense  industry’s 
IT  contractors,  as  well  as  some  non-defense  IT  contractors.  The  follow-on  responses  to  the  RFI 
were  also  impressive,  but  there  appears  to  be  no  effort  to  make  use  of  the  suggestions 
submitted.  By  the  March  2002  deadline,  over  forty  proposals  were  submitted  in  response  to  the 
G1  RFI.  However,  since  that  time,  the  responses  have  lingered,  their  distribution  limited,  and 
the  G1  has  not  published  a  Request  For  Proposal  (RFP)  for  their  personnel  transformation 
effort. 

With  regard  to  the  industry  day  discussion,  one  of  the  more  significant  issues  is  personnel 
community  migration  as  an  impediment  to  transformation.  It  was  interesting,  but  not  surprising 
to  note  the  most  frequently  asked  questions  during  industry  day  centered  on  whether  or  not  this 
effort  had  funding  within  the  Army’s  Program  Objective  Memorandum  (POM).  Unfortunately, 
the  answer  was  “partial”  because  the  G1  had  internally  reallocated  some  IT  funding  within  their 
funding  lines.  Most  of  the  effort  however,  was  listed  against  an  ‘Unfunded  requirement,”  or 
UFR.  Slightly  more  complicated  than  indicated,  the  personnel  IT  systems  represent  a 
significant  maintenance  bill.  The  personnel  community  is  in  a  conundrum  regarding  funding. 

The  major  portion  of  their  IT  funding  goes  to  maintenance  of  legacy  systems.  From  a  larger 
perspective,  the  Army  is  in  an  unprecedented  era  of  program  cancellations  and  scale-backs. 
Over  the  past  three  budget  years,  the  Army  has  terminated  over  forty  programs  and  reduced 
funding  on  over  twenty-five  programs  in  an  effort  to  fund  the  transformation  effort,  with  more 

terminations  and  cut-backs  likely.34  By  rights,  some  of  the  320  to  350  referenced  personnel 
systems  should  be  terminated  and  will  be  eventually.  However,  because  the  soldier  remains 
the  Gl’s  first  responsibility,  the  functions  legacy  personnel  systems  perform  must  continue. 

While  there  have  been  some  small  pockets  of  movement  towards  modernization,  with 
organizations  taking  it  upon  themselves  to  develop  a  modern  application  or  mini-system,  these 
have  been  largely  uncoordinated  with  any  enterprise  effort.  In  fact,  the  whole  of  the  personnel 
transformation  migration  plan  relies  on  movement  to  DIMHRS. 

Initially  replacing  forty-three  Army  systems,  the  latest  DIMHRS  schedule  lists  an  Army 
Initial  Operational  Capability  (IOC)  in  fourth  quarter,  Fiscal  Year  2004. 35  The  Navy’s  PEO  for  IT 
defines  DIMHRS  as  follows: 

The  mission  of  DIMHRS  Pers/Pay)  is  to  identify,  design,  develop,  prepare  for 

deployment,  and  maintain  standard  systems  to  support  military  personnel  and 
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pay.  This  includes  a  single,  standard  military  personnel  and  pay  system  from  field 
level  data  collection  to  headquarters  data  base  management  system  that  meets 
Office  of  the  Secretary  of  Defense  (OSD)  defined  requirements  and,  where 
appropriate,  Service-specific  requirements  for  all  components.  The  overall  goal 
for  DIMHRS  (Pers/Pay)  is  to  provide  fully  integrated  military  personnel  and  pay 
capability  for  all  Components  of  the  Military  Services  of  the  Department  of 
Defense  with  an  initial  operating  capability  by  2004.  The  program's  major 
objective  is  to  enhance  mission  support  to  the  war  fighter  and  Service 
Departments  by  eliminating  or  reducing  data  collection  burdens,  solving 
operational  problems,  conserving  resources,  improving  delivery  of  services,  and 
enhancing  readiness.36 


Following  Desert  Storm  in  1991,  DOD  recognized  the  myriad  of  stovepipe  personnel  systems 
throughout  each  of  the  services  were  incapable  of  supporting  how  DOD  would  conduct  military 
operations  in  the  future.  That  is,  since  the  personnel  systems  within  the  respective  services 
were  not  capable  of  interfacing  with  each  other,  they  certainly  could  not  support  joint  service 
operations.  From  this  recognition,  DIMFIRS  was  born.  There  have  been  problems  as  might  be 
expected  when  attempting  to  join  four  services’  personnel  and  pay  functions  into  a  single  entity. 
Flowever,  at  this  point  there  appears  to  be  progress,  although  there  are  significant  change 
requirements  for  each  of  the  services.  Relating  back  to  the  earlier  discussion  on  perspective 
and  the  difference  between  what  the  field  commander  saw  versus  what  FIQDA  looked  at,  one  of 
the  more  significant  changes  facing  the  Army  is  the  fact  that  DIMFIRS  will  manage  people  by 
position,  as  done  in  civilian  industry,  rather  than  by  unit  or  MACOM/installation.  This  will  require 
the  Army  to  change  how  they  manage  soldiers.  Whether  the  Army  and  the  personnel 
community  specifically,  will  be  flexible  enough  to  produce  the  tactics,  techniques,  and 
procedures  (TTP)  and  have  them  in  place  prior  to  DIMFIRS  implementation,  remains  to  be  seen. 

In  a  slightly  unorthodox  move,  the  DIMFIRS  program  office  selected  a  COTS  software 
package,  PeopleSoft  8,  in  March  2001,  before  it  had  selected  an  integrating  contractor.37 
PeopleSoft  had  been  previously  chosen  by  several  large  corporations  as  the  replacement 
software  package  for  their  human  resource  functions.  In  September  2002,  the  DIMFIRS 
program  office  awarded  a  development  contract  for  the  Phase  I  (Assessment  Effort)  to  five  IT 
contractors.  At  the  end  of  Phase  I,  expected  in  December  2003,  the  program  office  will  select 
one  of  the  five  as  the  integrating  contractor  for  the  entire  effort.  The  program  manager  has  said 
they  “are  looking  for  an  integrator  with  proven  experience  at  implementing  PeopleSoft  at  a 

o  o 

corporate  level.”  Program  office  emphasis  has  been  on  using  PeopleSoft  out-of-the-box, 
meaning  they  want  to  minimize  customizations  made  to  PeopleSoft  as  much  as  possible.  The 
DOD  Inspector  General  (IG)  report  from  June  2002  expressed  the  concern  that  “while  adoption 
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of  the  COTS  package  inherent  personnel  management  processes  will  diminish  the  need  for 
modifications,  DIMHRS  program  officials  also  need  to  adequately  consider  how  well  those 
processes  will  meet  user  requirements.’  Because  PeopleSoft  was  chosen  as  the  software 
package  so  long  ago,  several  organizations  have  had  opportunities  to  either  study  the  software, 
or  go  into  implementation  themselves,  benefiting  others  with  their  lessons  learned. 

The  Army  Human  Resource  System  (AHRS)  program  office,  responsible  for  SIDPERS-3, 
E-MILPO,  and  several  other  personnel  applications,  conducted  a  study  of  PeopleSoft  to 
compare  the  out-of-the-box  functionality  with  the  functionality  provided  in  the  legacy  SIDPERS-3 
system.  This  has  been  referred  to  as  a  fit  gap  analysis,  where  the  purpose  is  to  identify 
functionality  gaps  and  determine  the  resource  implications  resulting  from  those  gaps.  According 
to  the  June  2002  DOD  IG  report  on  DIMHRS,  “the  DIMHRS  program  manager  anticipated  that 
the  COTS  software  would  require  about  10  to  20  percent  modification  to  obtain  the  minimum 
functionality  required  by  DOD  users.”40  It  is  important  to  note  the  PM  AHRS  analysis  was 
limited  to  a  comparison  against  the  existing  functionality  in  a  single  legacy  system.  Considering 
DOD’s  human  resource  management  responsibilities  go  beyond  that  of  corporate  America,  the 
results  of  the  AHRS  analysis  were  not  surprising.  Specifically,  the  study  found  that  25% 
functionality  matched  out-of-the-box,  25%  would  match  with  some  slight  modifications  to  the 
software,  and  50%  of  the  functionality  resident  in  the  legacy  personnel  system  had  no  match  in 
PeopleSoft.41  This  is  not  to  say  PeopleSoft  would  not  work,  or  even  that  it  was  a  bad  choice  in 
software  packages.  The  study  should  serve  as  notice  to  the  defense  community,  or  to  at  least 
the  Army  personnel  community,  that  conversion  to  PeopleSoft  may  have  some  challenges  the 
personnel  community  should  be  prepared  to  address.  The  June  2002  DOD  IG  report  on 
DIMHRS  specifically  addressed  this  issue  in  detail,  citing  “prior  DOD  experience  with  COTS- 
based  human  resource  systems  indicated  that  it  may  be  unreasonable  to  expect  to  meet  80  to 
90  percent  of  the  required  functionality  with  an  “off  the  shelf”  application.’42  However,  the  PT 
TF  dismissed  much  of  the  AHRS  study  findings,  and  has  carefully,  reiterated  their  support  for 
PeopleSoft  as  the  DIMHRS  software  package,  including  the  requirement  to  minimize  out-of-the- 
box  customization.  In  the  meantime,  the  PT  TF  was  to  have  been  conducting  its  own  fit-gap 
analysis  to  determine  where  shortfalls  might  occur,  but  whatever  results  they  may  have 
generated  have  not  yet  been  made  public. 

One  of  the  organizations  implementing  PeopleSoft  8  as  their  human  resource  application 
is  the  Defense  Intelligence  Agency  (DIA).  The  Director  of  Human  Resources  for  DIA  stated  that 
PeopleSoft  8  can  do  anything  any  organization  needs  it  to  do  -  for  a  price.  The  Director  went 
so  far  as  to  say  that,  given  another  opportunity,  DIA  would  start  off  by  discarding  entirely  their 
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current  system  and  processes  so  they  could  move  directly  to  People  Soft  8.  They  would 
thereby  limit  customization  by  addressing  it  as  an  add  on  process  at  the  end  of  their  conversion, 

43 

using  it  only  for  those  critical  processes  clearly  not  available  in  the  software  package. 
Customization  is  extremely  expensive,  which  is  why  the  DIMHRS  program  office  is  trying  to  limit 
it  as  much  as  possible.  The  bottom  line  is  that  the  services  need  to  minimize  service-unique 
functionality  and  be  prepared  for  wholesale  departure  from  the  way  they  currently  conduct 
personnel  and  pay-related  business.  As  mentioned  earlier,  change  has  to  start  with  processes 
before  technology  can  be  brought  to  bear  in  the  transformation  process.  The  question  becomes 
one  of  whether  the  Army  has  made  that  cultural  shift  in  the  mindsets  of  its  employees  to 
recognize  process  change  is  required  and  inevitable. 

RECOMMENDED  APPROACH 

What  follows  is  a  three-step  approach  to  transformation  that  makes  some  assumptions 
about  the  Army’s  ability  to  change  the  cultural  mindsets  referred  to  previously.  Specifically,  the 
assumption  is  that  the  Army  will  be  successful  in  changing  the  personnel  community  mindset  at 
the  risk  of  failing  to  transform  its  personnel  systems  in  a  timely  enough  manner  to  support  both 
the  Army  Transformation  and  the  mandated  move  to  DIMHRS. 

The  first  step  that  needs  to  occur  is  to  move  the  personnel  systems  out  from  the  functional 
community  and  into  the  acquisition  community,  complete  with  the  associated  requisite  oversight 
actions  and  reviews.  The  personnel  community  will  likely  rail  at  such  a  suggestion,  citing  the 
poor  example  of  SIDPERS-3  and  the  over-budget  and  past-schedule  examples  associated  with 

events  prior  to  that  program’s  Milestone  III  decision  in  1998. 44  However,  close  inspection  of  the 
events  leading  up  to  the  milestone  decision  reveals  specific  causes  for  the  problems 
experienced  by  this  program. 

First,  no  one  from  either  the  functional  community  or  the  material  developer  side,  including 
the  pre-Milestone  III  product  manager  and  PEO,  held  the  functional  community  accountable,  or 
at  least  raised  a  red  flag,  for  requirements  changes  occurring  throughout  system  development 
and  continuing  almost  unabated  up  to  the  Milestone  III  decision  point.  Additionally,  the  chief 
engineer  most  closely  associated  with  the  architecture  must  share  some  blame  for  not 
identifying  significant  flaws  inherent  in  its  design.  The  hardware-starved  personnel  community 
desired  this  design  because  it  put  much-needed  workstations  in  the  hands  of  their  users. 
However,  the  result  was  over  4000  workstations  Army-wide  requiring  synchronization  for  the 
system  to  properly  represent  an  accurate  strength  accounting  picture.  Synchronization  of  4000 
computers,  while  possible  in  theory,  is  very  difficult  to  make  happen,  and  more  so  on  the  scale 
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of  once  or  twice-daily  as  required  for  SIDPERS-3.  Synchronization  for  SIDPERS-3  occurred 
through  a  custom  coded,  batch-mode  transaction  processor  which  would  process  transactions 
off-line,  during  off-hours.  This  prevented  the  application  software  from  performing  any  real¬ 
time  data  entry  integrity  checks,  referred  to  earlier  in  the  section  on  data  reconciliation.  The 
result  was  significant  and  continuous  data  errors  and  validity  problems  across  the  architecture. 
And  finally,  while  many  are  quick  to  blame  the  SIDPERS-3  contractors  as  desiring  more  to 
make  money  than  deliver  a  working  product,  the  SIDPERS-3  integrating  contractor  was  a 
government/Army  organization. 

While  there  are  certainly  examples  of  failed  acquisition  efforts,  the  state  of  the  personnel 
IT  systems  cannot  be  attributed  to  those  failures.  For  the  most  part,  the  current  state  of  these 
systems  was  self-inflicted  from  within  the  personnel  community.  But  the  Army  has  its  share  of 
responsibility  too.  By  focusing  solely  on  war-fighting,  it  ignored  events  in  the  non-war-fighting 
communities.  The  logistics  community’s  systems  were  in  much  the  same  state  in  which  the 
personnel  community  now  finds  itself.  It  has  only  recently  begun  to  make  improvements.  In  the 
long  term,  of  course,  this  has  been  detrimental  to  all  soldiers,  including  the  war-fighters,  and  the 
Army  has  a  price  to  pay  to  correct  the  problem. 

Going  back  to  the  funding  issue  as  the  best  tactile  indicator  showing  the  community’s 
investment,  the  personnel  system’s  current  IT  budget  is  estimated  to  be  between  $200M  - 
250M  annually.47  If  nothing  else,  the  Army  community  at  large  should  recognize  the  dividends 
that  could  be  realized  if  the  maintenance  bill  could  be  cut  in  half.  If  the  personnel  community 
were  provided  a  family  of  systems  as  part  of  the  larger  Army  enterprise  effort,  the  Army  could 
reap  significant  funding  gains  for  use  with  the  Interim  and  Objective  Force  development  efforts. 
These  gains  would  be  realized  as  the  labyrinth  of  hundreds  of  stovepipe  personnel  systems 
were  replaced.  So,  while  there  always  needs  to  be  a  war-fighting  focus,  this  focus  does  not 
obviate  the  need  to  correct  long  overdue  deficiencies  in  the  non-war  fighting  systems.  This  has 
become  more  critical  in  this  era  of  budget  cuts,  especially  when  such  corrections  would  likely 
free  up  scarce  funding  which  could  be  redirected  to  the  war  fighter. 

The  second  in  the  three-step  approach  to  transform  the  personnel  systems  is,  on  paper, 
simple.  There  are  realistically  two  possible  paths  for  this  step.  The  first  is  the  clean  slate 
approach.  This  is  the  preferred  approach  because  it  is  likely  to  take  less  time  than  the  second 
possibility.  The  clean  slate  approach  is  where  the  personnel  community  determines  what 
functions  are  required  to  support  a  soldier  throughout  the  soldier  life-cycle,  enlistment  through 
separation.  Those  conducting  the  functionality  determination  must  remove  themselves  totally 
from  how  business  is  conducted  now.  They  must  also  identify  and  separate  those  functions 
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conducted  and/or  monitored  by  the  DOD  system,  and  those  conducted  by  the  Army  system. 

The  product  is  what  gets  coded  in  the  new  system,  and  the  legacy  systems  are  shut  off. 

The  second  possible  path  is  no  less  complicated,  requiring  a  thorough  analysis  of  the 
existing  functionality  in  the  legacy  systems.  It  entails  coming  up  with  a  plan  to  transition  off  the 
old  systems  while  figuring  out  what  functionality  soldiers  and  their  families  need  now  and  for 
tomorrow.  That  is,  examine  all  the  applications,  databases,  and  systems,  and  decide  which 
functionality  is  critical  and  must  be  maintained.  Applying  a  BPR  formula  of  threes,  each 
application  will  be  placed  in  one  of  three  categories:  1)  Critical  functionality  that  must  be  brought 
forward  into  the  new  system,  2)  Functionality  and/or  whole  systems  that  can  be  discarded,  and 
3)  Legacy  systems  (containing  necessary  functionality)  modern  enough  to  be  capable  of  being 
ported  to  interface  with  the  new  system,  at  least  until  the  functionality  can  be  replicated 
elsewhere  and  the  legacy  system  can  be  discarded.  This  is  not  going  to  be  a  clean  and  neat 
process  for  the  personnel  systems,  as  many  of  them  perform  duplicative  functions.  However, 
this  is  a  necessary  step  for  the  personnel  community  to  stop  hemorrhaging  maintenance  dollars 
on  these  antiquated  systems. 

The  third  step,  closely  aligned  with  the  second,  is  to  once  and  for  all,  establish  a  single 
corporate  database  for  Army  personnel,  including  all  three  components,  and  both  military  and 
civilian  employees,  with  the  possible  addition  of  contractors.  This  step  will  likely  be  the  most 
difficult  to  undertake,  given  the  cultural  schism  between  components,  and  the  fact  that  the  G1 
cannot  control  Reserve  Component  funding,  either  in  appropriation  or  execution.  Establishing 
this  database  is  necessary,  in  addition  to  the  DOD  DIMHRS  effort,  because  there  will  likely 
always  be  service-unique  functions,  or  even  data  elements  the  Army  wants  to  keep  track  of  that 
are  of  no  interest  or  value  to  DOD.  One  which  immediately  comes  to  mind  is  a  soldier's  eye¬ 
piece  prescription  for  use  as  protective  mask  inserts.  DOD  is  not  likely  to  keep  track  of  that 
level  information,  but  that  level  of  information  is  necessary  for  commanders  to  take  care  of  their 
soldiers. 

Work  on  this  corporate  database  has  actually  already  started,  under  the  ITAPDB  effort. 
The  physical  process  of  establishing  data  definitions,  and  the  cost  associated  with  a  data 
migration  effort,  will  be  complicated,  and  painful.  It  will  also  be  costly,  both  in  terms  of 
manpower  and  money.  Should  the  Army  choose  not  to  develop  a  corporate  database,  it  will  be 
held  hostage  to  first,  the  legacy  mainframe  TAPDB,  which  is  supposed  to  be  replaced  by 
DIMHRS  and  second,  by  whatever  dataset  DIMHRS  uses.  Neither  of  these  is  in  the  best 
interest  of  the  soldiers  the  personnel  systems  are  designed  to  support. 
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CONCLUSIONS 

The  personnel  community  has  gone  to  great  lengths  in  the  past  two  to  three  years  to  try 
and  reinvent  itself,  including  efforts  to  reduce  its  footprint  in  the  battle  space.  The  information 
provided  in  this  paper  indicates  the  community  is  also  talking  about  personnel  transformation  for 
its  legacy  systems,  but  whether  or  not  it  is  committed  to  transforming  them  remains  to  be  seen. 
The  single  most  difficult  obstacle  to  overcome  is  the  entrenched  ideology  of  “but  we  have 
always  done  it  this  way.”  The  fact  that  the  DOD  software  package  of  choice  is  an  off-the-shelf 
product  makes  that  ideology  more  than  obsolete;  it  makes  it  an  incredible  impediment  to 
change. 

The  number  of  320  to  350  applications,  databases,  and  systems  provides  too  many 
opportunities  for  “rice  bowls,”  and  nothing  in  transformation  points  to  those  rice  bowls  being  able 
to  survive,  much  to  the  dismay  of  their  owners.  This  gives  rise  to  rice  bowl  owners  being 
increasingly  protective,  even  defensive,  of  their  territory.  Everyone  can  argue  that  there  would 
not  be  that  number  of  personnel  systems  if  the  systems  provided  accomplished  their  assigned 
mission.  However,  the  Army  needs  the  personnel  community  to  not  only  forget  that  argument  - 
it  needs  them  to  become  the  fervent  disciples  of  transformation  required  to  kill  those  hundreds 
of  systems.  The  starting  point  remains  identifying  what  functions  are  truly  required  for  the  Army 
to  support  its  soldiers  from  the  point  prior  to  enlistment  through  the  end  of  that  enlistment  or 
retirement.  The  smartest  way  to  approach  it  would  likely  be  the  clean  slate  approach  described 
earlier.  In  terms  of  time,  the  Army  is  at  the  point  where  it  should  not  even  be  a  question  of  what 
existing  functions,  performed  by  existing  systems,  are  needed.  The  question  is  one  whose 
answer  delineates  what  personnel  functions  soldiers  need  just  before  they  raise  their  right  hand 
to  give  their  oath  until  the  time  they  separate  into  civilian  life.  The  Army  owes  them  modern  and 
accurate  processes,  and  the  personnel  community  owes  those  processes  to  the  Army. 

The  Army  has  passed  the  crossroads  of  transformation.  It  is  no  longer  deciding  which 
path  to  take,  but  danger  lies  in  the  fact  that  the  Army  might  not  be  prepared  to  fully  support  itself 
on  its  chosen  path.  The  personnel  community  has  to  be  flexible  enough  to  change  almost 
everything  about  its  current  processes,  and  follow  closely  with  systems  change  from  a  technical 
perspective.  To  date,  that  has  not  happened,  and  though  there  have  been  fits  and  starts  hinting 
it,  there  does  not  seem  to  be  a  clear  plan  in  the  personnel  community  to  manage  the  magnitude 
of  change  required  to  truly  transform.  Without  changing  the  myriad  of  personnel  processes 
currently  embedded  in  day-to-day  business,  personnel  transformation  will  remain  stagnant,  and 
the  personnel  community  will  significantly  impede  Army  Transformation.  Should  that  occur,  the 
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war-fighting  community  would  be  required  to  pick  up  the  reins  and  finish  the  task.  Then  it  would 
be  more  than  just  legacy  systems  made  obsolete  in  the  personnel  community. 
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Reserve  Component  Coordination  Council 

RFI 

Request  for  Information 

RFP 

Request  for  Proposal 

ROE 

Rules  of  Engagement 

SA 

System  Administrator 

SECARMY 

Secretary  of  the  Army 

SecDEF 

Secretary  of  Defense 

SIDPERS-3 

Standard  Installation/Division  Personnel  System  -3 

SOSA-HR 

System  of  Systems  Architecture,  Human  Resources 

SQT 

System  Qualification  Test 

S&T 

Science  and  Technology 

TAPDB 

Total  Army  Personnel  Database 

TTP 

Tactics,  Techniques  and  Procedures 

UCMJ 

Uniform  Code  of  Military  Justice 

UFR 

Unfunded  Requirement 

UIC 

Unit  Identification  Code 

USAR 

United  States  Army  Reserve 

use 

United  States  Code 

USD  (P&R) 

Under  Secretary  of  Defense  (Personnel  &  Readiness) 

USR 

Unit  Status  Report 

VCSA 

Vice  Chief  of  Staff  of  the  Army 

Y2K 

Year  2000 
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